Data communication networks may be generalized into at least two types: asynchronous and synchronous. Provided such networks remain independent, performance characteristics and transmission latencies are understood, and in many cases predictable. However, in light of the convergence of disparate networks, there arises a need to provide methods and systems for interconnecting asynchronous networks with synchronous networks. Asynchronous networks typically operate under well known protocols, including by not limited to, the Transmission Control Protocol (TCP), Internet Protocol (IP), User Datagram Protocol (UDP) to name but a few. A well known synchronous network approach includes time division multiplexing (TDM), which can allocate particular data channels to predetermined time slots.
One very particular application for interconnecting asynchronous and synchronous systems includes voice data. Conventional voice data examples will now be described.
Conventionally, voice data remains separate from network data traffic. In particular, many enterprises may have a data network connecting a variety of workstations as well as a public branch exchange (PBX) for voice data. As data networks proliferate, it is becoming an increasingly desirable goal to integrate transmission of voice and data onto a converged network “backbone.”
Transmitting data over a synchronous network, such as a time division multiplex (TDM) voice system can be inefficient, as such systems typically transmit voice and data in predetermined frames. Frames are allocated portions of bandwidth, usually formed according to a time division multiplexing scheme. In the event voice or data traffic drops, a frame may be transmitted with only voice or data, thus wasting available bandwidth.
Transmitting voice over a data network (voice over network) can provide advantages over other approaches. Voice over network can take advantage of existing network structures. Further, as noted above, networks (including the Internet) continue to grow in size and in bandwidth. Voice over network can be more efficient than data over voice as such systems are typically packet based. In a packet based system, bandwidth is used as needed. When data is transmitted, a data packet can be sent through the network. When voice is needed, a voice packet can be transmitted through the network.
Voice over networks can provide additional cost savings as voice may be transmitted between locations without incurring conventional toll charges. This can be particularly true for systems that transmit voice over the Internet.
Many networks can be “connectionless” networks. Connectionless networks can provide multiple possible paths between source and destination. Consequently, in some cases, voice transmitted over such networks may be more reliable as voice data can reach a destination even if some of the network nodes are not operational. One type of voice of network approach utilizes the Internet protocol (IP), and is often referred to as voice-over-IP (VoIP).
Data networks may take a variety of forms. As noted above, a data network may be a connectionless network, including the Internet. Further, a network may include portions that are overlaid and/or integrate connection-oriented legs. Such systems include Internet protocol (IP) over asynchronous transfer mode (ATM), IP switching systems, and multiprotocol label switching (MPLS), or similar switching systems.
One possible drawback to transmitting voice data over connectionless networks, or networks having connectionless portions, can be the potential for different portions of the same voice stream arriving out of sequence. For example, a stream of voice data is typically broken down into samples and transmitted in a particular sequence over a network. However, while such samples can be transmitted in order, because packets may travel along different legs of a network, a sample may arrive out of order. Still further, it is possible for packets to be dropped. Thus, a voice sample may never arrive at a desired destination.
In contrast to many non-voice applications, in voice over network arrangements, voice data needs to reassembled in the same order that it was transmitted with minimal latency. This can be difficult to achieve with many conventional approaches.
Various proposals for implementing voice over data networks have been proposed. One general approach is the idea of a network “gateway.” A network gateway can provide access to a network (such as the Internet) for a variety of conventional voice data sources (voice channels). As but one example, a network gateway can be an IP gateway that integrates a PBX with an IP network. In such an arrangement, users may make telephone calls that appear entirely conventional, but are in fact being transmitted over a data network.
One drawback associated with voice over data networks can be the latency introduced by such approaches. Various sources may contribute to latency. A transmitting source introduces some delay in placing the voice into packet form. Typically the voice data can be digitized and/or compressed and then placed in packet form. Transmission of the voice over a data network can also introduce latency. Routing from node to node, or along a switching path, can consume additional time. Finally, a receiving destination can introduce delay. Voice data can be extracted from a packet and then transmitted along an appropriate voice channel. Such packet processing can be conventionally accomplished with a general purpose processor.
According to one conventional approach, a network voice packet can be forwarded to a destination according to conventional protocols, such as the Real-time Transport Protocol (RTP). A destination can include conventional network hardware, such as a network interface card, which can receive the packet. A general purpose processor can then extract voice data within the packet (including any decoding/decompressing) and then play the voice data over sound card, or the like. Such computation steps can contribute significantly to latency.
According to another conventional approach, a network can include a network phone (such as an “IP Phone”). A network phone can have its own network address, and include packet processing and voice data processing hardware.
One conventional way to decrease latency is with more complex routers. In particular, some routers may be capable of giving particular packets precedence over others. As but one example, some packet headers can include a “type of service” or “quality of service” field. A network voice packet can be given higher precedence than other packets, thereby reducing latency when compared to other packets. A drawback to such approaches is that all routers/switches in the network must have such an advanced processing capability, and thus can be expensive to implement. Consequently, such an approach may be better suited for enterprise wide area networks (WANs), instead of a larger network structure such as the Internet.
Another approach can essentially reserve a route for a voice packet flow. One such approach is the Resource ReserVation Protocol (RSVP). RSVP, like the precedence approach noted above, can rely on more complex routers and thus be an expensive solution.
While the approaches described above can reduce latency for voice packet data, such approaches may be difficult and/or expensive to implement. Further, it is still desirable to reduce latency even more. Thus, further ways of decreasing latency in network voice packets could a valuable contribution to voice over data networking.
While conventional packet forwarding of voice a data network may provide adequate results, this may not always be the case. To help improve the processing of time dependent data, including voice data, a number of protocols have been proposed. One such protocol is the Real-Time Transport Protocol (RTP). An RTP header can provide sequence and timestamp information than may help assemble voice data once it has been received.
Another concern that may arise out of voice over network systems is different possible voice data formats. Some formats may require different processing than others. Further, the processing of one voice format type may take longer and/or require more resources than other voice formats. Different voice formats may include, as but two of the many possible examples, “multiplexed” voice packets, which can contain voice data from multiple sources, and “simplex” voice packets, which may contain voice data form a single source. With the advent of multiplexed and simplex voice packets, systems may have to be capable of accommodating both types of voice packets.
Multiplexed voice data can present a challenge to voice-over-network systems. In particular, it can be a complex task to extract multiple voice samples from different voice streams, and then arrangement such samples for playback.
Voice over networks systems are typically “asynchronous” in that voice data samples may arrive at varying time intervals and/or in varying order. This is in contrast to conventional “synchronous” voice systems, such as TDM systems, that reserve time slots for particular voice channels. An important issue arriving out of systems that seek to transfer voice data from an asynchronous system to a synchronous system can be variable network delay in voice data arriving from an asynchronous system (jitter).
Of course, it is understood that voice data represent but one of the many applications for interconnecting asynchronous and synchronous systems. A system for accounting for network jitter could have various other applications that transmit data from an asynchronous network to a synchronous network. Such alternative applications include, but are not limited to other non-voice data applications, including but not limited to video data and various other computing applications.
In light of the above, it would be desirable to arrive at a system that can receive data from an asynchronous network, and store such data for synchronous access by a synchronous network. Such a system could address various drawbacks to conventional approaches, and could be particularly valuable in voice over network applications.